default capabilities cleanup #3484
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Planning to enable the new |
|
Out of curiosity, would a 'nimble node' also be a possible node capability value? |
I'm imagining a "nimble" node as having a limited or reduced set of capabilities. |
jaspervdm
approved these changes
Nov 21, 2020
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We previously set node "capabilities" explicitly in the config file.
The capabilities are then advertised to peers via hand/shake protocol.
This makes it hard to introduce new capabilities (for example PIBD support) as every node has these effectively hard-coded in their existing config files.
And every node needs to update the config to explicitly enable new capabilities.
This PR removes this configuration and simply defines "default" capabilities. This "default" can now change over time without explicit modification of the config file.
One (surprising and probably unexpected) thing we used node capabilities for was to express an "affinity" toward other peers. When requesting a peer address list we asked for peers that exhibited the same capabilities as our local node.
I don't think this ever makes sense, particularly in an environment where peers have heterogenous capabilities.
Nodes should advertise their local capabilities and it should be up to other nodes to decide, based on these capabilities, how to interact. A node wants to know about a wide range of other nodes, not just those that appear similar.
This PR modifies the "peer address list" logic to request lists of peers that themselves are also capable of providing lists of peers. No other capabilities are required. Previously we only asked for
FULL_NODE(i.e. full set of capabilities) peers.Introduce a new
PIBD_HISTcapabilities flag, currently unused and currently not included in default capabilities.This PR should make it significantly easier to roll PIBD out across nodes incrementally. Only a subset of nodes may support PIBD initially.
We may want to introduce support for disabling some capabilities over time. This is outside the scope of this PR.